1. Field of the Invention
The present invention relates generally to a ciphering method in a mobile communication system supporting a Multimedia Broadcast/Multicast Service (MBMS), and more particularly to a method for notifying UEs of a start time for using ciphering parameters.
2. Description of the Related Art
In the mobile communication industry, the current trend is to provide a packet service (i.e., a multicast multimedia communication service) for transmitting a large amount of packet or circuit data as well as voice communication data. A Broadcast/Multicast Service for providing services from at least one multimedia data source to a number of UEs is under development to support the multicast multimedia communication service. The broadcast/multicast service can be classified into a Cell Broadcast Service (CBS), which is a message-based service, and a Multimedia Broadcast/Multicast Service (MBMS), which supports multimedia formats such as real-time images and audio, still images, and text data.
The CBS service broadcasts messages to all UEs located in a specific service area, which is, for example, the entire area in a cell where the CBS service is provided.
The MBMS service supports multimedia formats such as real-time images and audio, still images, and text data at the same time, and thus, requires a large amount of transmission resources. The MBMS service is provided through a broadcast channel because a large amount of service may be simultaneously provided in a single cell. In particular, the MBMS service requires a larger amount of radio resources than the CBS service.
The MBMS service can be provided in a Point-to-Point (PtP) mode or in a Point-to-Multipoint (PtM) mode according to the number of UEs intending to receive the MBMS service in a cell or according to transmission power used for the MBMS service. The PtP mode provides a desired MBMS service to each UE over a dedicated channel assigned thereto when there are a small number of UEs desiring the MBMS service or when there is sufficient remaining transmission power. The PtM mode provides desired MBMS services to UEs over a common channel assigned thereto when there are a large number of UEs desiring the MBMS service or when there is insufficient remaining transmission power. Of course, when the MBMS service is being provided in the PtP mode, the service mode can be switched to the PtM mode on a cell-by-cell basis or when the MBMS service is being provided in the PtM mode, the service mode can be switched to the PtP mode on a cell-by-cell basis. This mode switching is performed only when there is a change in an environment providing the MBMS service.
FIG. 1 is a block diagram illustrating an example of a mobile communication network supporting MBMS services when the network is applied to an asynchronous mobile communication system. In FIG. 1, a Broadcast/Multicast-Service Center (BM-SC) 106 is a source that provides MBMS streams. The BM-SC 106 schedules and transfers MBMS streams to a Gateway GPRS (General Packet Radio Service) Support Node (GGSN) 105. The GGSN 105 transfers the MBMS streams received from the BM-SC 106 to a Serving GPRS Support Node (SGSN) 103. The SGSN 103 is included in a Core Network (CN) and connects the CN with a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) 102. The SGSN 103 receives the MBMS stream from the GGSN 105, and performs control associated with MBMS services for subscribers that desire to receive the MBMS services.
For example, the SGSN 103 manages MBMS service charging data of each subscriber or selectively transmits MBMS streams to a specific Radio Network Controller (RNC) in the UTRAN. The SGSN 103 also includes and manages an SGSN service context for MBMS services. The service context for MBMS services is a set of control information items required to provide the MBMS services. A Home Location Register (HLR) 104 is connected with the SGSN 103 to perform subscriber authentication for MBMS services.
As illustrated in FIG. 2, a User Equipment (UE) 101 is connected with the UTRAN 102 through a Uu interface 121, which is a term used in 3GPP to describe an interface between the UE and the UTRAN. The UTRAN 102 is connected with the SGSN 103 that is included in the CN via an Iu interface 122 illustrated in FIG. 2, which is a term used in 3GPP to describe an interface between the UTRAN and the components of the CN.
Table 1 below describes the role of each MBMS component illustrated in FIG. 1.
TABLE 1MBMSComponentsRolesUETo receive MBMS data allowing user to use the service at any time.UTRANTo transfer MBMS data to UE and transfer MBMS request of UE to CN.SGSNTo authenticate UE requesting MBMS service based on data received from HLR,and authenticate the right to use requested MBMS service based on data receivedfrom HLR.To establish Radio Access Bearer (RAB) for MBMS service requested by UE.To support MBMS services also when UE moves between cells and provideconnection with MBMS source via GGSN.To collect charging information of MBMS service used by UE.HLRTo manage information for authentication of each UE and information of MBMSservice types usable by each UEGGSNTo receive MBMS data to be provided to UE directly from Multicast/Broadcastsource through BM-SC and BG and transmit received MBMS data to SGSN.To collect charging information of UE, manage movement states of each UE, andmanage QoS of MBMS service provided to UE.BM-SCTo authenticate content provider, determine QoS of MBMS service, correct errorsof lost MBMS data, charge content provider, and receive MBMS data fromcontent provider and provide it to GGSN.To inform UE of which MBMS service is currently provided to UE.Multicast/BroadcastTo provide MBMS data directly to GGSNsourceBGTo receive MBMS data from Multicast/Broadcast source in network not currentlymanaged by service providerContent ProviderTo provide MBMS content to BM-SCMulticast/BroadcastTo provide MBMS data directly to GGSNsource
The description of the roles of the MBMS components in Table 1 may differ slightly according to network operators, but their basic roles are the same as in Table 1.
Although not illustrated in FIG. 1, the network may further include a Cell Broadcast Center (CBC) for providing UE with preliminary information about MBMS currently in service.
Table 2 describes the types and roles of interfaces used for the MBMS components illustrated in FIG. 1.
TABLE 2Interface typesRolesUuInterface between UE and UTRANIuInterface between UTRAN and CNGrInterface between SGSN and HLRGn/GpInterface between SGSN and GGSNGiInterface between GGSN and BMSCGiInterface between GGSN and multicast/broadcast sourceGiInterface between GGSN and BGGn/GpInterface between BM-SC and content providerGiInterface between BG and multicast/broadcast source
Although terms defined in 3GPP are used to describe the interfaces in Table 2, different terms may also be used.
The configuration of each component of the communication network supporting MBMS services illustrated in FIG. 1, the configuration of the UTRAN, and protocol and channel structures used in 3GPP will now be described in detail with reference to FIGS. 2 and 3.
Referring to FIG. 2, the UTRAN includes a plurality of Radio Network Systems (RNSs) 110 and 120. The RNSs 110 and 120 include RNCs 111 and 112, Node Bs 115 and 113, and Node Bs 114 and 116, which are controlled by the RNCs 111 and 112, respectively, and a plurality of cells belonging to each of the Node Bs 115, 113, 114, and 116. The RNC 111 or 112 controls the Node Bs 115 and 113 or the Node Bs 114 and 116 and provides an MBMS service to a Node B, where a UE requesting the MBMS service is located, among the Node Bs 115 and 113 or the Node Bs 114 and 116 managed by the RNC 111 or 112. The RNC 111 or 112 also controls a radio channel for providing an MBMS service, and includes and manages an RNC service context for the MBMS service provided by the RNC 111 or 112. The service provider can determine the total number of Node Bs controlled by the RNC 111 or 112 and the total number of cells belonging to each Node B.
FIG. 3 illustrates the protocol architecture of a conventional UTRAN. More specifically, FIG. 3 illustrates a detailed configuration of the higher layer and channels between the layers in the UTRAN currently defined in the asynchronous mobile communication system.
Referring to FIG. 3, messages of the higher layer processed in the UTRAN can be mainly divided into a control signal (i.e., a control plane (C-Plane) signal 301) and user data (i.e., user plane (U-Plane) data 302). The C-Plane signal 301 and the U-Plane data 302 are messages of a Non Access Stratum (NAS). The NAS messages are not used for radio access between the UE and the UTRAN, and thus, the UTRAN does not need to know the information of the NAS messages. Different from the NAS messages, Access Stratum (AS) messages are directly used for radio access between the UE and the UTRAN. More specifically, the AS message is data or at least one control signal used in a Radio Resource Controller (RRC) 303.
The RRC 303 controls a physical layer (L1) 310 associated with connection between the UE and the UTRAN, and also controls sub-layers of Layer 2, such as Medium Access Control (L2/MAC) 308, Radio Link Control (L2/RLC) 306, Packet data Convergence Protocol (L2/PDCP) 304, and Broadcast/Multicast Control (L2/BMC) 305. Through this layer control, the RRC 303 controls all events or operations associated with connection between the UE and the UTRAN, such as physical call establishment, logical call establishment, control information transmission/reception, and measurement data transmission/reception between the UE and the UTRAN.
The L2/PDCP 304 receives data, which will be transmitted, from the NAS layer, and transmits the received data to the L2/RLC 306 using a suitable protocol. The L2/BMC 305 receives data required for broadcast/multicast from the NAS layer, and transmits the received data to the L2/RLC 306 using a suitable protocol.
The L2/RLC 306 receives a control message to be transmitted from the RRC 303 to the UE, and processes the received control message into a format suitable for its characteristics in RLCs #1 to #m 361 to 362. The processed control message is transmitted to the L2/MAC 308 through a logical channel 307. The L2/RLC 306 also receives data from the L2/PDCP 304 and the L2/BMC 305 and processes the received data into a suitable format in RLCs #1′ to #n′ 363 to 364. The processed data is transmitted to the L2/MAC 308 through the logical channel 307. The number of RLCs produced in the L2/RLC 306 is determined based on the number of radio links existing between the UE and the UTRAN.
The logical channel 307 is mainly classified into a dedicated type for a specific UE or a specific set of UEs, a common type for a plurality of UEs, a control type for transmission of control messages, and a traffic type for transmission of traffic data or messages.
Table 3 describes the types and roles of logical channels used in the asynchronous mobile communication system.
TABLE 3LogicalchannelsRolesBCCHUsed for downlink transmission of UTRAN system controlinformation from the UTRAN to a UE.PCCHUsed for downlink transmission of control information fromthe UTRAN to a UE when the location of a cell to which theUE belongs is not known.CCCHUsed for transmission of control information between thenetwork and a UE when the UE has no connection channelwith the RRC.DCCHUsed for point-to-point transmission of control informationbetween the network and a UE when the UE has a connectionchannel with the RRC.CTCHUsed for point-to-multipoint data transmission between thenetwork and UEs.DTCHUsed for point-to-point data transmission between the networkand a UE.
In Table 3, “BCCH” stands for Broadcast Control Channel, “PCCH” stands for Paging Control Channel, “CCCH” stands for Common Control Channel, “DCCH” stands for Dedicated Control Channel, “CTCH” stands for Common Traffic Channel, and “DTCH” stands for Dedicated Traffic Channel. Under the control of the RRC 303, the L2/MAC 308 manages radio resources and a connection between the UE and the UTRAN. The L2/MAC 308 also receives logical channels from the L2/RLC 306 and maps the received logical channels to transport channels 309 to transmit them to a physical layer (L1) 310.
Table 4 describes the types and roles of the transport channels 309.
TABLE 4TransportChannelsRolesBCHMapped to a BCCH to transmit data of the BCCH.PCHMapped to a PCCH to transmit data of the PCCH.RACHUsed for transmission of network access and control messagesand small-size data from a UE to the network, and can bemapped to DCCH, CCCH and DTCH.FACHUsed for transmission of control messages and data from thenetwork to a specific UE and a specific set of UEs, and can bemapped to BCCH, CTCH, CCCH, DTCH and DCCH.DCHUsed for transmission of data and control signals between thenetwork and a UE, and mapped to DTCH and DCCH.DSCHA downlink channel from the network to a UE, used for highvolume data transmission, and mapped to DTCH and DCCH.HS-DSCHA downlink channel from the network to a UE, whichimproves transmission efficiency of DSCH, and mapped toDTCH and DCCH.
In Table 4, “BCH” stands for Broadcast Channel, “PCH” stands for Paging Channel, “RACH” stands for Random Access Channel, “FACH” stands for Forward Access Channel, “DCH” stands for Dedicated Channel, “DSCH” stands for Downlink Shared Channel, and “HS-DSCH” stands for High Speed DSCH. There are also transport channels such as an Uplink Shared Channel (USCH) and a Common Packet Channel (CPCH) other than the transport channels described in Table 4, but a description thereof is omitted in Table 4 because they are unrelated to the present invention.
Through a suitable procedure, the transport channels transferred to the physical layer (L1) 310 are mapped to actual physical channels and are then transmitted to the UE or UTRAN. The physical channels include a Primary Common Control Physical Channel (P-CCPCH) for transferring the BCH, a Secondary Common Control Physical Channel (S-CCPCH) for transferring the PCH and FACH, a Dedicated Physical Channel (DPCH) for transferring the DCH, a Physical Downlink Shared Channel (PDSCH) for transferring the DSCH, a High Speed Physical Downlink Shared Channel (HS-PDSCH) for transferring the HS-DSCH, and a Physical Random Access Channel (PRACH) for transferring the RACH. Pure physical channels other than the above physical channels, which do not carry higher layer data or control signals, include a Pilot Channel (PCH), a Primary Synchronization Channel (P-SCH), a Secondary Synchronization Channel (S-SCH), a Paging Indicator Channel (PICH), an Acquisition Indicator Channel (AICH), and a Physical Common Packet Channel (PCPCH).
The MBMS service generally provides one or more services to a number of UEs as described above, and thus requires a suitable ciphering method. Ciphering in communication systems protects PtP data transmitted to a subscriber or transmitted from a subscriber to a communication provider, and the ciphering method has been specialized to accomplish this purpose.
The ciphering method generally uses a ciphering algorithm and parameters required for the algorithm. The same ciphering algorithm may provide different ciphering results by using parameters of different values. For cost savings, most communication systems use a small number of ciphering algorithms and a large number of parameters in encoding data transmitted and received by the user.
The conventional ciphering method and the MBMS ciphering method used for MBMS data are similar in that encoded data is transmitted. The two ciphering methods generally use a small number of algorithms, rather than a large number of algorithms, and renew parameters for the algorithms to obtain different ciphering results. However, the two ciphering methods have different data reception ranges. The conventional ciphering method is based on PtP communication, whereas the MBMS ciphering method is based on PtM communication. This difference causes some problems in the MBMS service.
For example, some UEs may attempt to illegally receive the MBMS service by exploiting the fact that the MBMS service is provided to a number of UEs. In addition, some UEs that have subscribed to a specific MBMS service may attempt to receive other MBMS services using a ciphering method used for the specific MBMS service.
Taking into account the similarities and differences, the MBMS ciphering method will have the following requirements as compared to the conventional ciphering method.
First, the MBMS ciphering method requires a method for reliably transmitting parameters for use in a ciphering algorithm to UEs that have subscribed to the MBMS service.
Second, parameters for use in a ciphering algorithm must be renewed at appropriate times to encode MBMS data for an MBMS service such that only authorized UEs can receive the MBMS service at any time.
Third, UEs must be correctly informed of when renewed parameters are to be used so that the UEs can correctly decode MBMS data. In particular, asynchronous mobile communication systems have no method of synchronizing the network with a number of UEs and informing the UEs of when the renewed parameters are to be used. Therefore, there is a need to provide a method suitable for informing the UEs of when the renewed parameters are to be used.